1. Field of the Invention
This invention relates to packet or frame buffering for frame handling devices.
2. Description of Background Art
Local area network ("LAN") traffic, by its nature tends to be transmitted in bursts. Hence, it is often necessary for an Ethernet driver (software interface between Ethernet controller and operating system and/or Ethernet data link layer) to buffer a number of Ethernet frames before they are actually processed by the higher layers of the protocol software. This buffering at the driver/Ethernet controller interface is especially important in an embedded environment where processor power is not always available.
Typically, a memory shared by the Ethernet driver and the Ethernet controller is divided into a plurality of same size buffers. It is a common practice for the size of the buffers to be determined by either the largest size incoming frame or the largest size frame that will be processed by the higher layers. When this is the case, if the buffer size used is much larger than the typical size of an incoming frame, many of the buffers are underutilized. Hence, a substantial amount of buffer space is wasted. Additionally, with a shared memory of limited size, the use of large buffers may result in there not being enough available buffers to store repeated small bursts of data, when the processor is busy performing other tasks. Hence, large buffers that are too few in number may result in frames being lost.
To make the most out of the buffer space available in the shared memory, some Ethernet controllers are provided with the ability to data chain buffers. This feature enables the driver to receive a frame larger than a buffer since the frame can be split up over multiple buffers. However, when this data chaining feature is used, if the buffer size chosen is smaller than the average size of all incoming packets, the driver might spend a substantial amount of time parsing through buffer descriptors attempting to re-assemble packets. This can be costly as to processing resources. On the other hand, if the buffers' size is made too large to reduce the amount of data chaining, then the above problems of underutilizing the buffers and/or shortages in the number of buffers may occur. Hence, there is a tradeoff between wasting buffer space (and therefore requiring more memory or losing data because of not being able to handle minimal network loading) and wasting processing power (and therefore requiring more processing power or losing functionality or data).
When designing an Ethernet driver for an Ethernet controller which supports data chaining, it is necessary for the software developer to determine the most appropriate size for the frame buffers taking into account the above tradeoffs. Since the designer can only guess what the average size frame to the unit in the field might be, it is difficult to find a medium solution in which both problems can be eliminated.
Many Ethernet controllers use descriptor tables or rings to organize incoming and outgoing data or frame buffers. Each descriptor is associated with a buffer. Within the descriptor is the size and location of the buffer as well as flags that describe the status of the buffer. These flags are used by the Ethernet driver and controller to determine who is currently in control of the buffer and if the buffer has data in it or not. For Ethernet controllers that support data chaining, the flags also specify whether the data in the buffer is the start, middle or end of the frame. For incoming Ethernet frames, the controller stores the data for each frame in a buffer and marks the buffer as being full in the descriptor. If the frame is too big to fit in one buffer, it will be split up among multiple buffers if the controller supports data chaining. Since the Ethernet driver is responsible for passing packets to the higher protocol layers, it is its responsibility to re-assemble them.